Because of the rapid growth in the complexity of microprocessors, various methods have been developed for expediting the verification of a design prior to its actual implementation in hardware. Most of these methods relate to functional testing which uses information concerning desired behaviors specified by the designer of the microprocessor during a design phase. For example, these methods typically evolve around functional tests which use the instruction set of the microprocessor. Such functional testing has been generally proven to be reliable and robust.
In the typical scenario, a hardware design language is used to develop a register and logic gate level description of the processor in software. The functional test programs can then be written in any convenient computer language such as C++. The functional test is then run on the hardware description language model of the processor. The relative effectiveness of functional test programs depends upon how quickly the functional test can be completed, how well the functional model can be examined for errors, and the time required to generate the test software.
In general, two different techniques have evolved for developing functional test programs, including random generation and manual generation. The oldest method for developing functional test programs is write them manually. Typically, the functional test is implemented as a specialized program written by one of the hardware designers. While these types of programs are typically more expensive to develop and consume much programming time, they are often more effective than randomly developed sequences, since they can be written to target a particular feature of the microprocessor.
The known methods for manually generating test programs have a number of problems. For example, functional models that are tested using manually written programs may contain errors that the designers of the programs did not contemplate. The time that it takes to write a functional level test by hand versus the limited number of tests and limited variety of test sequences also makes manual testing a long and involved process.
Methods that use random instruction generators are considered to be inexpensive and efficient in many applications, and experience has been that they optimize the cost and speed at which errors can be found. With this technique, instruction sequences are produced by generating random binary patterns and then automatically translating them into an instruction sequence.
Unfortunately, randomly generated tests are not necessarily well adapted for determining whether a design will correctly execute all types of instruction sequences. For example, certain functions which are desirable to test may involve a particular sequence of internal instructions and external events. However, such external events are ordinally not synchronized with clock signals that determine the internal events.
Consider, for example, an external probe command of the type which is provided by another processor which is external to the microprocessor being tested but which contains a request for access to shared resource such as memory locations. Such probe commands usually have an address associated with them whereby the external processor is attempting to gain access to a shared memory location which is already being cached by the processor.
It is quite possible for an error in the hardware design for implementing a probe command to cause the microprocessor to produce an incorrect result when certain sequences of these activities occur. For example, the state of the cache memory of the processor under test and other registers may be critical as to whether the probe command is correctly handled. In order to devise an effective test for such an activity, access to the internal state of the processor is therefore typically required.
The problem with using randomly generated test programs is that they are not as effective in testing for known combinations of internal and external events. Ideally, in order to test microprocessor logic, the data or address associated with the test probe command relates in some way to data or an address which is already in use by the microprocessor or otherwise derived in some way from its present state.
Synchronization problems also develop with such an approach, since it takes a while typically for a probe command to reach over the system bus and arrive at the processor under test.